Minor: this regex matches RFC 3986 scheme syntax, which is the right call. Worth noting it also matches Windows drive letters like C:/path, but that's harmless since (a) those would never appear as Rollup external specifiers, and (b) the \\ startsWith check above catches the backslash variant.

One thing I noticed: the node: prefix check that was in the original code (specifier.startsWith("node:")) is now redundant since the regex catches it. But removing it was the right move — the regex is more general and handles virtual:, file:, data:, etc. all at once. Clean.

Checking both specifier and packageName against builtins is a nice touch — handles fs/promises (where the specifier itself is a builtin subpath) and bare builtins like crypto (where packageName equals the specifier). The builtinModules list includes entries like fs/promises directly, so both paths are necessary.

Nit: scoped packages (@scope/pkg) aren't checked against BUILTIN_MODULES before returning. This is fine because no Node builtin starts with @, but it does mean if Node ever added a @node/something builtin (unlikely), it would slip through. Not worth changing, just noting the asymmetry for future readers.

Good fallback strategy. resolve.paths() is stable Node API and gives the same lookup directories that require.resolve() would search. The pkg.name === packageName guard on line 87 prevents false positives from similarly-named directories that aren't the right package (e.g., a stale directory left over from a different version).

Nit: the as { handler: Function } cast is a reasonable workaround for Vite's plugin types (where writeBundle can be either a function or an object with handler). If this pattern shows up in more tests, it might be worth a small getPluginHook test helper to reduce the casting boilerplate, but fine as-is for a single test.

Consider adding a few direct unit tests for packageNameFromSpecifier — it's now exported and the logic is non-trivial (regex, builtin set, scoped packages). The integration test here is valuable but a table-driven unit test would catch regressions faster and document the edge cases explicitly. Not blocking — the integration test covers the important paths.